1. Field of the Invention
The present invention relates to a parallel distributed processing system for performing network-wide multimedia parallel processing and a method of the same.
2. Description of the Related Art
In recent years, there has been active development of ISMs (Information Super-Markets), that is, information supplying and utilizing service applications for enabling the utilization and circulation of multimedia information. In an ISM, to enhance the dialog among facility modules and the flexibility of the inter-module structure, an application execution environment enabling efficient network-wide multimedia parallel processing is required. In response to this, a "parallel distributed process system" has been developed.
In such a conventional parallel distributed processing system, a facility call is made among modules by using the module name and facility name (method name) indicated by a character string. Here, a "facility call" means the call and use of a facility provided in another module in processing carried out in a certain module.
A typical example of a parallel distributed processing system is the CORBA (Common Object Request Broker Architecture)--ORB (Object Request Broker). Here, the CORBA is a mechanism for intercommunication of software operating at a plurality of computers connected to a network and serves as the basis for flexibly and efficiently constructing a distributed system. Further, ORB is software performing the communication among objects and facilities to transfer a message received from a client object to a suitable server object via the network.
In the CORBA-ORB, the management space of the objects is defined as the entire environment supported by the system.
Further, in the CORBA-ORB, when a certain module calls a facility of another module, the facility name and arguments defined as symbols are transferred from the module originating the call to the module receiving the call. The module receiving the call is provided with a table of correspondence between the facility names and the execution addresses of the programs for executing the facilities. The module receiving the call obtains the execution address by searching through the correspondence table and executes the facility which is called.
Further, a parallel distributed processing system wherein description is made of a method of distributed allocation and execution of programs with which the user can describe the program without being conscious of which network node the module is arranged in is disclosed in Japanese Unexamined Patent Publication (Kokai) No. 3-226856.
In this method of distributed allocation and execution of programs, a private directory for designating the name of the network node in which each module is arranged is provided. The description of an external call existing in a source program is automatically rewritten (amended) by the system while referring to this directory.
Further, the above-mentioned type of parallel distributed processing system is often constructed using the Internet. In the Internet, an IP address and a DNS (domain name system) name are given to the nodes on the network. The IP address is an identification number of each data processing device connected to the network and is expressed by a 32 bit number. Further, the DNS name is a name enabling differentiation of nodes on the network by a symbolic name having meaning to the users. The network is divided into management ranges and a name given to each range. The DNS (domain name system), which is a hierarchical naming mechanism using DNS names comprised by the series of names divided by periods establishes a hierarchy of the machine names in the Internet based on the TCP/IP.
Note that, these IP addresses and DNS names must not overlap on the network, that is, through the world, and are centrally managed by a network information center (NIC).
In the conventional CORBA-ORB, however, since the module receiving the call uses the facility name indicated by the character string as a key to refer to the table and specify the execution address, and there are the problems that the cost for specifying the execution unit is large and the efficiency of the processing accompanying the facility call is poor.
Also, in the CORBA-ORB, the format of the arguments accompanying a facility call must be separately defined at the time of compilation. At this time, the data structure of the arguments which can be defined is limited to simple one such as structure and array, thus there is the problem that complex data structures such as linked data structures cannot be used.
Further, in the CORBA-ORB, the module receiving the call must exist (be registered) in advance. Further, there is the problem that it is basically necessary to define the format of the call facility and arguments at the time of compilation, thus when trying to dynamically download (additionally register) and use a module receiving a call, the work becomes troublesome.
Further, in the CORBA-ORB, when the system of synchronization for performing the facility call is different, a different programming interface (API) must be used, thus there is the problem that the description of the program becomes complex.
Further, in the conventional CORBA-ORB, the management space of the objects is defined as the entire environment supported by the system, therefore the user cannot freely define a management space having as a range of management only the required objects according to the particular purpose.
Accordingly, there is a problem that the user must maintain uniqueness of the names even for unnecessary objects in the wide area of the system even when using only part of the objects for a particular purpose and otherwise manage the system, thus the load accompanying this management is heavy.
Further, in the CORBA-ORB, since it is necessary to maintain the uniqueness of names in the wide area of the system, there is the problem that the same names cannot be used among a plurality of applications supported by the system, thus the degree of freedom of the names usable in each application is low.
Further, since the objects are managed in the wide area of the system in this way, there is the problem that the number of the objects to be managed becomes enormous and the search time when accessing an object becomes long.
Further, there also exists the problem that dynamic (incremental) space management accompanying addition, deletion, etc. of the computation modules and so on is difficult.
Further, in the method of distributed allocation and execution of programs disclosed in Japanese Unexamined Patent Publication (Kokai) No. 3-226856, since the description of the external call existing in the source program is amended while referring to the directory, there is a problem that, if the contents of the directory are changed in accordance with the change of the module allocation, it becomes necessary to newly compile the source program, so the processing accompanying the change is troublesome and cannot be quickly handled.
Further, in the DNS, which is widely spreading as the name solution mechanism for objects, the conversion of the reference information is a simple one such as conversion from a DNS name to an IP address. Namely, it cannot only handle a single step of conversion and thus cannot be used for such complex name solutions that requires multi-stage conversion. Further, it cannot adequately handle complex reference information that is based on a plurality of pieces of information either.
This means that the DNS is not suitable as the reference mechanism used in a more sophisticated parallel distributed processing environment as mentioned before. Namely, this is because, in such a parallel distributed processing environment, it is necessary to efficiently refer to various computation resources and various objects on the network by using various names and ID's, but the DNS cannot handle such a reference solution.